To communicate timing performance targets to logic design tools (or electronic design automation, EDA, tools) for field programmable logic devices (FPGAs), designers specify timing constraints such as, for example, clock period constraints, IO TSETUP requirements, and IO THOLD requirements. Based on these timing constraints, EDA tools attempt to generate design implementations which satisfy user performance targets. EDA tools also report whether the specified timing constraints have been satisfied so the designer can take steps, if necessary, to try to improve the design implementation. The designer may, for example, change EDA tool settings or impose constraints, such as placement and routing constraints, on the EDA tool.
Clock period timing constraints may be specified as performance targets. The minimum clock period for a given register-to-register path in a design is primarily a function of three delays: the maximum path delay between the two registers, the maximum path delay from the clock to the source register, and the minimum path delay from the clock to the destination register. The difference between the last two components is typically referred to as the clock skew for the two respective registers. Minimizing the maximum path delay between the two registers to minimize the clock period is the focus of most EDA optimization. EDA tools often ignore clock skew between registers during optimization, because clock signals are typically distributed on low-skew routing resources or networks. Low-skew routing resources ensure that clocks will be distributed with low “predictable” skew to allow optimization tools to focus on register-to-register delays when attempting to satisfy clock period constraints. However, when designs have more clocks than the number of available low-skew networks, some clocks need to be distributed using regular resources that are not specifically designed to be low-skew and this motivates low-skew optimization techniques and analysis.
Some inter-chip board-level communication standards rely on low-skew transfers where the goal is to have signals arrive at approximately the same time regardless of the absolute time it takes the signals to travel from source to destination. To support design implementation for these standards, low-skew optimization techniques and analysis methods are beneficial.
There are other instances, when low-skew (or zero-skew) is not of interest and so dedicated resources can not often be employed. Instead the designer would like to enforce a particular skew schedule and, in those cases, path-level low-skew optimization and analysis techniques that address skew schedules are of interest.
For the purposes of this application, low-skew or zero-skew requirements (or constraints) will be referred to as simple skew requirements (or constraints). When skew schedules are involved, those respective constraints will be referred to as complicated skew constraints. Complicated skew constraints have two types of skew schedules: source skew schedules and destination skew schedules. A source skew schedule specifies how much slower paths from different sources should be with respect to one another, for any given destination. For example, a source skew schedule may be that all paths starting on source node A are X ps slower than all paths starting on source node B, for any given destination node. The reason that the schedule only applies for any arbitrary destination node, rather than across all destination nodes, is because source skew schedules may be used with destination skew schedules. A destination skew schedule specifies how much slower the paths ending at different destinations should be with respect to one another, for any given source. For example, a destination skew schedule may be that all paths ending on destination node C are Y ps slower than all paths ending on destination node D, for any given source node. Simple skew constraints are a subset of complicated skew constraints with zero source and zero destination skew schedules, which is equivalent to no source and destination skew schedules (with source and destination skew schedules that specify that the delays of all paths emerging from sources should be equal and the delays of all paths ending at destinations should be equal). It should be noted that a source skew schedule can apply across all destination nodes rather than only for any arbitrary destination node if a zero destination skew schedule is specified. Similarly, it should be noted that a destination skew schedule can apply across all source nodes rather than only for any arbitrary source node if a zero source skew schedule is specified.
Before automatic path-level skew optimization techniques, designers in the past had to manually repair design implementations to satisfy skew constraints. This often required that the user manually insert logic, adjust the placement, and/or routing of the design, or redesign the system to accommodate the skew present in the design implementation.
Thus, what is needed is an efficient method and apparatus for satisfying path-level skew constraints. Also needed are path-level skew analysis techniques to help measure how well skew constraints have been satisfied.